Processing critical information relies on the security of the computing platform. Typical security goals are to prevent such critical information from leaking beyond the realm of machines that are trusted by the user or to prevent corrupted machines from impacting the integrity of a computation. External verification of platform integrity enables a machine to verify that another machine meets certain security requirements. This is useful, for example, when a grid server wants to assure that a grid node is untampered before delegating a grid process to it.
In the following example two computers or machines A and B interact over a network, wherein in reality A and B might be two computers or two operating system images living on the same computer in parallel or even might be the same entity. In the example machine A can make certain statements about its own state, e.g. “I am . . . ” or “My software . . . is in status x”, or deliver a hash or checksum of this status (h(x)), or certain properties, e.g. “I am running version . . . of Linux”. Machine A can send these statements to machine B, but why should machine B trust machine A with respect to the correctness of these statements? If machine A is corrupted by a hacker, it could make arbitrary claims about itself.
Therefore, it is necessary to implement a proving method with which machine B can verify whether the statements made by machine A are correct. The embodiment of such a proving method is shown in FIG. 1. In the following, machine A is called verified machine or the prover and machine B the verifier. All solutions to this problem assume that there is a piece of hardware, called trusted platform module TPM, which cannot be compromised, and which can make reliable statements about the rest of the system A. Specifically, the industry consortium Trusted Computing Group (TCG) has specified the trusted platform module TPM, which can compute a checksum of the system configuration of machine A, wherein the checksum can be computed for a system configuration in which all or only a part of the software is running on machine A. In a further step the computed checksum is signed, and afterwards send off to the verifier B. The corresponding protocol is shown in FIG. 2.
The Trusted Computing Group is an IT industry consortium which has developed a specification of a small, low-cost commodity hardware module, called trusted platform module (TPM). The TPM can serve as a root of trust in remote (and local) platform verification. The base TCG model of this configuration verification process, called binary attestation, aims at measuring all executed code. Therefore, each measured piece of software stores metrics of a sub-component into the TPM before executing it, wherein the metrics are hash values of the configuration's components. The metrics are bootstrapped by the basic input output system (BIOS) that is trusted by default and that is measuring and storing the boot loader. The chain of trust can then be extended to the operating system components and to the applications and their configuration files. Once the executables are measured into the TPM, the TPM can reliably attest to the metrics of the executed components by signing the metrics with a TPM-protected key. The signed metrics, also called integrity metrics, can then be transmitted to a verifying machine. This verifier machine, or in short verifier, can decide whether to consider the verified machine trustworthy enough to involve it in a subsequent computation. As will be elaborated hereinafter, this straightforward approach of binary attestation lacks scalability, privacy, and openness. The main reason is that the whole configuration is transmitted (limited privacy), that the verifier needs to know all configurations of all machines to be verified (limited scalability), and that the verifier checks binaries that are specific to a vendor and operating system (limited openness).
Hereinafter, the binary attestation and verification is explained. The ability of the TPM reliably to report on the verified platform's computing environment follows from the TPM-enabled measurement and reporting. The measurement and storage of integrity metrics is started by the BIOS boot block (a special part of the BIOS which is believed to be untampered) measuring itself and storing the measurements in a TPM PCR (platform configuration register) before passing control to the BIOS. In the same way, the BIOS then measures option ROMs and the boot loader and records these measurements in a TPM PCR before passing control to the boot loader. The process continues as the boot loader measures and stores integrity metrics of the operating system (OS) before executing it. The OS in turn measures and stores integrity metrics of additionally loaded OS components before they are executed. If support by the OS is provided, applications can also be measured before being executed. The measurement and reporting processes are depicted in a simplified manner in FIG. 2, in which ′H represents the cryptographic hash function SHA-1. During initialization, various platform configuration registers PCRx as well as a configuration log file log (stored on the platform) are initialized. This log file log keeps track of additional information such as descriptions or file paths of loaded components. Its integrity need not be explicitly protected by the TPM. During subsequent measurement of components, this log file log is extended, while metrics (hash values) of the executables are stored in the TPM using the tpm_extend method replacing the contents of the appropriate platform configuration register PCRx with the hash of the old contents and the new metrics, wherein metrics of loaded components are reliably stored in the TPM. When a remote verifier B wants to assess the security of the verified platform A, the verifier B sends a challenge c to the platform A. The platform A uses this challenge c to query with a tpm_quote command the TPM for the value of the platform configuration registers PCR. The TPM responds with a signed message signAIK({right arrow over (PCR)}, c) containing the PCR values and the challenge c. The platform A returns this signed quote to the challenger (verifier B) together with information from the log file needed by the verifier to reconstruct the verified platform's configuration. The verifier B can then decide whether this configuration is acceptable. The key used for signing the quote is an attestation identity key AIK of the TPM. As a TPM may have multiple attestation identity keys, the key or its identifier has to be specified in the tpm_quote request. An attestation identity key AIK is bound to a specific TPM. Its public part is certified in an attestation identity key certificate by a privacy-certification authority as belonging to a valid TPM. The verifier of a quote signed with a correctly certified AIK believes that the quote was produced by a valid TPM, more specifically, by the unique TPM owning that AIK. This belief is based on the assumption that the TPM is not easily subject to hardware attacks and that effective revocation mechanisms are in place dealing with compromised keys.
Note that the above measurement process does not prohibit execution of untrusted code, it only guarantees that the measurement of such code will be securely stored in the TPM. Thus, if malicious code is executed, the integrity of the platform A may be destroyed. However, the presence of an untrusted (or simply unknown) component will be reflected by the TPM quotes not matching the correct or expected values.
The checksum computed by the trusted platform module TPM depends on all details of the configuration, which means there will be an extremely large number of different checksum configurations corresponding to trustworthy. Thus, this solution disadvantageously does not scale: in general the verifier B will need to know which checksums are the trustworthy ones, and hence the only way for the verifier B is to enumerate all the correct values, which obviously works for small, closed systems only. It will not work for open systems. This approach is known as binary attestation. Further information about the Trusted Computing Group and the trusted platform module can be found in The Trusted Computing Group, Main specification version 1.1b, 2003, which is available from http://www.trustedcomputinggroup.org.
The trusted platform module TPM also supports trusted booting, which means that the prover A can go through a sequence of steps. In each step a new component is loaded e.g., first the boot loader, then the operating system, and then an application. The TPM ensures that critical data will be accessible and third party-recognized attestations can be produced by a given software layer only if that layer and all previous ones are occurring as part of a known, well defined execution sequence.
A related, theoretically well investigated feature is secure booting. The difference to trusted booting is that a system with secure booting either boots a specific, pre-defined system or does not boot at all, while a system with trusted booting can boot any system, but certain data are accessible only if it boots into a pre-defined system. The details of how a secure boot process can be carried out can be looked up in B. Yee, “Using secure coprocessors”, Technical Report CMU-CS-94-149, Carnegie Mellon University School of Computer Science, May 1994.
The binary attestation mentioned requires the verified platform to transmit to the verifier a cryptographically-strong checksum of essentially its entire configuration and current status. Such precise configuration information provides not only a scaling problem for the verifier, but also a privacy problem for the verified machine: the exact configuration is likely to provide a great deal of disambiguating information, perhaps sufficient to completely identify the platform which is requiring verification. Moreover, this approach violates the fundamental principle of good privacy-aware engineering, by answering a simple question—the verifier's query of the security state of the verified machine—with a great deal of superfluous information—the entire configuration of the verified machine.
Further, binary attestation by requiring a machine to transmit its entire configuration to the verifier allows, or even encourages, vendors to offer services over the network only to those platforms which are running software which the vendor recognizes and approves of, not simply to all platforms running software with the needed security properties. Thus binary attestation is inherently discouraging of openness in the software arena.
The fundamental problem with the TCG model of attestation is that checksums have no inherent semantics, they are just bit strings. The only way for the verifier to give them meaning is to compare them with other checksums for which that meaning is known a priori.